SPEC-PRD-SAL · v0.4 29 June 2026 Owner: Platform team
Sales — product requirements
RiverSync's funnel begins long before a deal: a centralized contact graph of the people and companies we deal with feeds a lead, which we qualify into an opportunity, whose chosen variant we confirm into the deal → quote → close the platform already carries. This PRD consolidates the platform-wide sales requirements (master §7, SAL-1…8) into one standalone spec; RiverSync runs it in the Pipeline app, with Partners sharing referral and follow-up.
DraftNew — consolidates SAL-1…8
Inherits the master PRD. The contact graph, lead front door, opportunity, partner lead-sharing and activity timeline are defined platform-wide in SPEC-PRD §7 (SAL-1…8). This PRD is the sales-scoped view across apps; on any conflict the master wins and the discrepancy is logged in both revision histories. Model invariants: DM-43…52 in SPEC-ERD / Pipeline ERD. Domain: the Sales bounded context. Behaviour: Lead to opportunity → Quote to cash. Lifecycles: Sales data workflow.
1The journey, end to end
A prospect exists in our world before any deal — a person at a company, reachable, related. The funnel's mature right-hand side (deal → quote → won → provisioned) is unchanged; this PRD specifies the missing middle and front: a contact graph, a lead, and an opportunity that shapes the deal.
Contact graphPeople & companies & relationships
→
LeadAn inquiry off a contact, by source
→
OpportunityQualified pursuit · variants compared
→
Deal → QuoteConfirmed from a variant, quoted
→
Won → provisionedDevice, agreement, invoice
2One funnel, several surfaces
Sales is a RiverSync-run domain. The Pipeline app is its home; Partners participates through referral and shared follow-up; downstream apps consume the deal it produces.
App
What it does with the sales model
Pipeline
Runs the whole funnel — Contacts + relationship graph, the Leads inbox across all six sources, Opportunities with variant compare, confirm-to-deal, and the existing deal/quote/close (PIP-9…14)
Partners
Speaks the same five-rung funnel as a role-scoped Sales group (PAR-12): a reseller refers a lead, works shared leads / opportunities, registers the Deal and follows it to Close; a distributor sees a masked Deal · Quote · Closed roll-up (PAR-10/11, PRT-11/12)
Account
Receives the bridge: an organization contact promoted to a customer Tenant on conversion (SAL-2, customer onboarding)
A unified-inbox thread on one channel, anchored to a contact (SAL-9)
Message
One message in a conversation, with direction & delivery state (SAL-9)
Deal.SourceOpportunity
Provenance field on the existing deal (SAL-6)
RiverSync Co., Ltd. · BangkokSPEC-PRD-SAL · 1
4Requirements
The eight platform requirements (master §7), restated with acceptance criteria. IDs and meaning are the master's; this PRD adds the detail apps build to.
SAL-1
Centralized contact management — the relationship graph. We keep one record of every person and company we deal with: a Contact of kind organization (a legal entity) or person (a human). Organizations form a group-of-companies hierarchy (parent ⇄ subsidiaries); a person has an employer organization and a manager (the reporting line); a general ContactRelationship graph captures the wider network (influences, introduced-by, advises). The graph is queryable top-down to deep-dive a prospect and drive the sale (DM-43).
Acceptance
A contact detail resolves the whole network in one view — the group above, the people inside, the reporting line between them.
The three spine ties (ParentId, EmployerId, ManagerId) are typed FKs and cycle-free; edges enforce From ≠ To.
A contact carries a Status — prospect · active · dormant · disqualified — and an owning RiverSync sales user.
SAL-2
The contact graph is distinct from tenancy. It records prospects and the wider buying network — parties that need no login and are not billed — and is never merged with the operational Tenant / Organization / ApplicationUser model. A contact bridges to that model only on conversion: an organization contact may link to a customer Tenant (CustomerId, 0..1), a person contact to a user account (ApplicationUserId, 0..1). An unconverted prospect holds neither (DM-44).
Acceptance
Creating a prospect contact never creates a tenant, a login, a bill or an access grant.
Conversion is the only path that sets CustomerId, joining hands with customer onboarding.
Extending Federation's Organization to hold prospects is explicitly rejected (decision H).
SAL-3
The lead is the single inbound front door. Every net-new inquiry enters as a Lead raised off a contact, owned by a RiverSync sales user; we qualify it, then either convert it (SAL-5) or disqualify it. A renewal, or a direct opportunity RiverSync opens itself, is the only exception (DM-46).
Acceptance
A lead names the person ContactId who inquired and, when known, the OrganizationContactId (DM-45).
Net-new pursuits never enter directly at Deal.intake — that path is retired in favour of the lead.
Lead lifecycle: new → working → qualified → converted, with disqualified as a soft, audited terminal (LIF-1, DWF-2).
SAL-4
Leads carry their source. One of six: online registration form, telephone, showroom walk-in, trade show, social network, or partner referral. Trade-show and social leads may attach to a marketing Campaign for attribution; deeper marketing automation is out of scope — we model attribution, not a marketing suite.
Acceptance
Every lead records a Source; Campaign is optional (0..1) and earns its place on trade-show/social leads.
All six sources share one lifecycle and one inbox — only Source and the attached referrer/campaign differ.
Channel mix and source effectiveness are answerable from Source + Campaign alone (§6).
SAL-5
A lead converts to an opportunity, not straight to a deal. Conversion resolves the customer — matching an existing customer organization or creating one (joining hands with customer onboarding) — and opens an Opportunity. It is one-way and recorded; the lead is never re-opened (DM-48).
Acceptance
Conversion writes Lead.ConvertedOpportunity and bridges the organization contact → Tenant (SAL-2).
Only a qualified lead may convert; the act emits lead.converted.
SAL-6
The opportunity is where the deal is shaped. It holds one or more variants — quantified configurations (models, quantities, maintenance tier) we compare — and the customer-validated variant is confirmed into a Deal, which carries §5's channel and proceeds to quote and close. The deal is the committed, quotable commitment; the exploratory, multi-option work lives on the opportunity (DM-49, DM-50).
Acceptance
An opportunity holds 1..n OpportunityVariants; at most one is selected.
The confirmed variant seeds the Deal's QuoteLines and writes Deal.SourceOpportunity; the Deal starts at confirmed (its old intake/qualifying stages move up to the opportunity).
A partner-attributed/assigned opportunity seeds Deal.PartnerAttrib so channel rules (DM-22…25) apply unchanged.
SAL-7
RiverSync can share a lead or opportunity to a partner. Assigning it (AssignedPartner) hands follow-up to that partner — gated by the partner's program tier (lead sharing, PRT-15); the partner works it in the Partners app and, on a win, registers the deal through its channel (PRT-11). Reuses the existing tier benefit, not a new mechanism (DM-47).
Acceptance
Sharing emits lead.assigned; the partner sees only what its scope permits.
Availability is gated on the partner's tier entitlement (Authorized · Gold · Platinum), resolved by the existing tier→entitlements map (DM-40).
SAL-8
Every touch is logged on one activity timeline. Emails, calls, visits, surveys, meetings and notes are logged as activities against the contact and, where relevant, the funnel stage. A contact's timeline blends these human-logged touches with the journey's own milestones (lead captured … deal won) into one navigable, bird's-eye history — distinct from the immutable audit trail and from support messaging (DM-51, DM-52).
Acceptance
Every activity is anchored to a Contact and may relate to one funnel entity (lead/opportunity/deal/quote).
Activities are owner-editable and audited; milestones are read-only — the two render in one column on the DS Timeline.
SAL-9
One unified communications inbox feeds the funnel. Every inbound and outbound message with a contact — across the web contact form, email (sales@riversync.com), the social channels LINE · Instagram · Facebook · LinkedIn, and logged phone calls — is centralized in one threaded inbox foldered Inbox · Draft · Sent · Archived · Junk · Deleted. A Conversation is one channel thread anchored to a contact and optionally a funnel record; sending/receiving a Message also writes an Activity so the blended timeline (SAL-8) stays the single history (DM-53, DM-54).
Acceptance
A conversation carries exactly one Channel and one Folder; it is anchored to a Contact (a pre-tenant prospect's lives wholly in the graph) and may relate to one funnel entity.
Junk and Deleted are reversible soft states; deleted is retained per policy (soft-delete, LIF-1). Replies and forwards go out on the conversation's own channel — Forward carries the conversation, Forward all the entire thread (every message) — each emitting conversation.forwarded.
Each message writes an Activity (email · call · social) so the contact's bird's-eye timeline surfaces it; this layer is distinct from customer↔support messaging (ChatThread).
RiverSync Co., Ltd. · BangkokSPEC-PRD-SAL · 2
5The contact graph
One model, the classic party pattern: a single Contact whose Kind is organization or person. Every node is a Contact; the edges make it a graph. Two built-in tree hierarchies plus an open graph:
Legal-entity hierarchy — an organization's ParentId points at another organization, building the group-of-companies tree.
Employment — a person's EmployerId points at the organization they work for.
Reporting line — a person's ManagerId points at another person (self-referential).
The wider graph — ContactRelationship carries everything else (influences, introduced-by, advises, board-member…), queryable without forcing every tie into a tree.
The bridge to tenancy — the rule that keeps this clean. The contact graph and the operational Tenant / Organization / ApplicationUser model both have companies and people, but answer different questions and stay distinct:
Contact graph (CRM) — owned by Sales
Tenant / Organization / User (operational) — owned by Federation
Anyone we deal with — prospects, the wider buying network, people with no login.
Parties that have signed up: a tenant with a login, billed, with roles & access.
A relationship graph: hierarchy, reporting lines, influence.
An authorization model: one user, one tenant, app roles, permissions.
An unconverted prospect lives wholly here, holding no bridge.
Joined only on conversion — never merged (DM-44).
6The lead & its six sources
A lead points at contacts — the person who inquired and, if known, their organization, both already nodes in the graph. The six front doors group into three families, which is how marketing reads the mix:
Source
Family
Notes
online-form
Digital
The online registration form on riversync.com — the only fully self-service capture; lands as new, owner unset.
social
Digital
Inquiry from a social network — naturally ties to a Campaign (which post / platform).
telephone
Human
A sales user logs the call; contact created or matched in the graph on the spot.
showroom
Human
Walk-in to the showroom — logged with the model of interest already seen.
trade-show
Human
Met at an event — the event is a Campaign instance; attribution matters most here.
partner
Channel
Reseller referral — carries PartnerAttrib; routes to that partner (PAR-10).
newcaptured from a source
→
workingassigned, qualifying
→
qualifiedreal — ready
→
converted→ Opportunity
·
disqualifiedsoft, audited
A working/qualified lead may terminate at disqualified — soft-deleted and audited (LIF-1, DWF-2). No hard deletes.
RiverSync Co., Ltd. · BangkokSPEC-PRD-SAL · 3
7The opportunity & its variants
A qualified lead is interest, not a commitment. The Opportunity is where we work that interest into something real: explore variants — different configurations of model mix, quantity, tier or site rollout — quantify each, and validate the one the customer will buy. Only a validated opportunity with a chosen variant is confirmed into a Deal, which is then quoted. This is the stage the funnel was missing.
Opportunity → OpportunityVariantSales domain
An Opportunity resolves its customer at create (SAL-5) and holds 1..n OpportunityVariants — each a configuration with its own estimated value and a status of considering · selected · rejected. The selected variant is recorded as ConfirmedVariant and seeds the Deal's quote lines. Deal.SourceOpportunity records provenance.
exploringfrom a converted lead
→
solutioningvariants quantified
→
validateda variant selected
→
confirmed→ Deal
·
declinedno fit / lost
May terminate at declined (no fit / lost) — soft, audited. The Deal then starts at confirmed and proceeds quoted → won/lost.
8Partner lead-sharing
RiverSync can assign a lead or opportunity to a partner to follow up — reusing the tier-gated lead-sharing benefit already in the partner program (PRT-15). The partner works it in the Partners app and, on a win, registers the deal through its channel (PRT-11). Two partner touchpoints on the funnel:
Partner touchpoint
What it is
Refer a lead(PAR-10)
A reseller raises a lead with Source = partner, carrying PartnerAttrib; it routes to that partner and into the shared queue.
Shared leads / opps(PAR-11)
Leads or opportunities RiverSync set AssignedPartner on, for the partner to follow up — gated by program tier (DM-47).
9The activity timeline
Every meaningful touch with a contact is an Activity — anchored to a contact, optionally related to a funnel stage, so the same record shows on the person's history and on the stage it concerns. The contact detail renders a blended, bird's-eye timeline on the DS Timeline: human-logged activities (editable) interleaved with system milestones (read-only).
Activitythe touchpoint log
Type email · call · visit · meeting · survey · note; a direction (inbound · outbound · internal), an OccurredAt on the timeline, the owner who logged it, and an outcome. Distinct from AuditEvent (immutable system facts) and ChatThread (support messaging) — Activity is the human relationship log, editable by its owner and audited like everything else.
RiverSync Co., Ltd. · BangkokSPEC-PRD-SAL · 4
10App surfaces
Pipeline (RiverSync only) gains a Contacts group above the Leads inbox and the new Opportunities surface, then the existing funnel. Partners now adopts the same five-rung funnel as its own Sales nav group (PAR-12) — a reseller across all five, a distributor from the Deal — refer/shared leads included. App-level requirements live in those app PRDs; this is the platform view.
PipelineRiverSync
Relationships
ContactsPIP-9
Sales
LeadsPIP-10
OpportunitiesPIP-11
Deals
Quotes
Closed
Channel
Partner tiers
Conversions
Contacts is the centralized directory; opening any contact gives the deep-dive — the full relationship network and the activity timeline you funnel down to drive the sale.
Leads is the inbound queue across all six sources; converting a lead opens an Opportunity where variants are quantified, and confirming one creates the Deal that proceeds to Deals, quotes and Closed. RiverSync can also share a lead or opportunity to a partner to follow up.
One funnel, three lenses. The five rungs are one shared record set. RiverSync (Pipeline) is the system of record and owns all five; a reseller works the whole ladder on its own + shared records; a distributor enters at the Deal as a masked roll-up. Each party acts on the same Deal with its own authority; the hand-offs are domain events (lead.assigned · lead.converted · opportunity.confirmed · deal.registered · deal.channel-changed · deal.won). The full stage × party responsibility map lives in SPEC-APP-PAR §3.
11Decisions — settled
The proposal's open decisions, resolved as recommended and cascaded across the spec families. Logged here for the record.
H
Contact graph distinct from tenancy, bridged on conversion. Extending Federation's Organization to hold prospects is rejected — it would pollute tenancy, billing and access. SAL-2 · DM-44
I
Typed-FK hierarchies + a general graph edge. Constrained trees (parent · employer · manager) plus an open ContactRelationship for the wider network. SAL-1 · DM-43
J
The contact graph lives in the Sales context for now; it graduates to its own context only if other domains need it. Sales domain
L
The Opportunity sits between Lead and Deal. The Deal becomes the confirmed, quotable commitment; intake/qualifying move up to the opportunity. SAL-6 · DM-50
M
Variants are OpportunityVariant children — quantified configurations, at most one selected, which seeds the quote. SAL-6 · DM-49
N
Lead-sharing reuses the tier-gated benefit (PRT-15), not a new mechanism. SAL-7 · DM-47
O · P
One contact-anchored Activity, rendered on the DS Timeline, blending milestones. Editable activities + read-only journey milestones in one column. SAL-8 · DM-51/52
C
Source attribution now, Campaign optional, no automation. Trade-show/social leads attach a campaign; a marketing suite is out of scope. SAL-4
12Open questions
Contact de-duplication. When a telephone/showroom lead is logged, how aggressively do we match against existing contacts to avoid duplicate parties in the graph?
Campaign depth. Is Campaign a flat attribution tag, or does it gain its own small lifecycle (budget, dates, channel)? Held until a marketing owner is named.
Graduating the graph (decision J). If Support or Field need the relationship graph, the contact context graduates out of Sales — tracked, not yet triggered.
RiverSync Co., Ltd. · BangkokSPEC-PRD-SAL · 5
13Traceability
Each requirement to its model invariants, owning entities and the apps & workflows that realize it. Full matrix in SPEC-ERD §5.
First draft — consolidates the platform sales requirements (master §7, SAL-1…8) into a standalone Product PRD: the contact relationship graph and its distinctness from tenancy, the lead front door and its six sources, lead→opportunity conversion, the opportunity and its variants, partner lead-sharing, and the blended activity timeline. Restates each requirement with acceptance criteria, the settled decisions (H/I/J/L/M/N/O/P/C) and a traceability matrix to DM-43…52 and the ERD/DDD/PWF/DWF families. No new requirement IDs — inherits the master's; on conflict the master wins.
0.2
28 Jun 2026
Unified communications inbox (SAL-9 added). Restates the new platform requirement with acceptance: one threaded inbox centralizing web form · email · LINE · Instagram · Facebook · LinkedIn · phone, foldered Inbox · Draft · Sent · Archived · Junk · Deleted; a Conversation is one channel thread anchored to a contact, and each Message also writes an Activity (SAL-8). Entity dictionary gains Conversation · Message; traceability adds SAL-9 → DM-53 · DM-54. Cascaded from master SAL-9; realized in SPEC-APP-PIP (PIP-15).
0.3
28 Jun 2026
Inbox forwarding (SAL-9 amended). A conversation can be Forwarded (the conversation) or Forward all'd (the entire thread — every message) on its own channel; each forward composes a new outbound message, writes an Activity and emits conversation.forwarded. Cascaded to DM-54 (ERD), the conversation.forwarded event + /sales/conversations/{id}/forward route (DDD), the Communications process (PWF) and the Conversation lifecycle (DWF); realized in SPEC-APP-PIP (PIP-15).
0.4
29 Jun 2026
Partners adopts the funnel ladder (§10, §2 updated). The Partners app now renders the same five rungs — Leads · Opportunities · Deals · Quotes · Closed — as a role-scoped Sales nav group (a reseller across all five, a distributor from the Deal), not just Refer/Shared leads. §10 and the §2 surface table updated; added the one funnel, three lenses responsibility note pointing at the three-party map in SPEC-APP-PAR §3. Aligned with SPEC-APP-PAR v0.8 (PAR-12) and SPEC-APP-PIP v0.14. No new platform requirement IDs — the funnel and SAL-1…9 are unchanged; this is the cross-app surface view.
